It irks me to add yet another feature just because of that, also given that once_cell is such a small and common crate. I think if we could we'd want to imply not enabling std to enable once_cell/critical-section. Since this isn't possible I'd instead argue it's better to just keep always depending on once_cell and point out to users that they have to use once_cell/critical-section if they want Sync. That's already the case with the PR as-is, only that a user also has to enable the once_cell feature. This would save us feature permutations, an extra code path and complexity for users. What do you think?

Agreed! The ideal solution (that we can implement without changes to Cargo or rustc of course) would just be to make once_cell a required dependency and add a critical-section feature to enable Sync support. This can be done, but doing so adds critical-section to the Cargo.lock file, which would necessitate a review of that crate and its usage of unsafe (which it does use). I'm happy to refactor this PR to do this, but I'm unsure if adding critical-section to the lock file is a non-starter.

I've split out the Mutex and RwLock changes into #7830, as they are a good fit for wgpu-types and would help with Naga and wgpu-hal too.

Sorry for the long lead times on these. It's been quite busy at work and I'm now out for a couple of days. Will likely get to it some point next week 🤞

No stress! Thanks for your help 🙂

finally getting coming back to this after a break! First of all, thanks for all the added docs, looks great now.
I'd like to discuss ways to reduce amount of features a bit more though, after all this quite significantly increases the number of permutations and thus technically the number of versions that ought to be tested.

The ideal solution (that we can implement without changes to Cargo or rustc of course) would just be to make once_cell a required dependency and add a critical-section feature to enable Sync support.

Not entirely sure I'm following it all the way: right now the PR exposes once_cell as a separate feature and expects anyone that wants to use no_std to do once_cell/critical-section if they want resource pool to be Sync. In other words there's a way to get to Sync but it requires --features once_cell/critical-section. If we were to drop once_cell feature and always depend on once_cell would this change then, or does cargo no longer allow --features once_cell/critical-section and requires you instead to add this to your application's Cargo.toml?

But either way we still end up with imho way to many hard to use feature knobs. I'm wondering if we instead should adjust a little bit:

• have parking_lot be directly implied by std without a parking_lot feature
  • parking_lot can't be used in a no_std environment anyways and it's what we always used for std so far
• two features to configure no_std - if cargo would allow it I'd definitely force-auto-enable those whenever std is disabled to cut down on things, but alas we can't:
  • add spin feature as done in this pr, have it yield to std like it yields in hits pr right now to parking_lot
  • add critical-section feature as you've described, replacing once_cell feature

@ErichDonGubler does Mozilla care about dependencies that show up in the lock file but aren't ever enabled in Firefox? Should be fine, after all we also have testing dependencies in the same situation, no?

@ErichDonGubler does Mozilla care about dependencies that show up in the lock file but aren't ever enabled in Firefox? Should be fine, after all we also have testing dependencies in the same situation, no?

So long as they don't show up in mozilla-central's Cargo.lock file, then 🤷🏻‍♂️ it's not something we have to vet, and therefore not something we might have to reject.